Среди компаний, имеющих в своей производственной среде виртуальную инфраструктуру VMware vSphere или Microsoft Hyper-V, многие применяют для защиты виртуальных сред средство vGate R2 от компании "Код безопасности", позволяющее безопасно настроить инфраструктуру согласно различным требованиям с помощью наборов политик, разграничить доступ администраторов, а также защититься от несанкционированного доступа к виртуальным ресурсам.
Новая версия vGate R2 3.0, прежде всего, отличается расширенными возможностями работы в распределенных инфраструктурах и изменением схемы лицензирования. В результате заказчики vGate смогут получить функционал продукта, в наибольшей степени отвечающий целям и задачам организации. Обновленная версия vGate (vGate R2 и vGate-S R2, релиз 3.0) поддерживает расширенный набор инструментов работы с платформами виртуализации VMware vSphere и Microsoft Hyper-V.
Ниже приведены основные нововведения новой версии vGate 3.0:
В vGate 3.0 реализована полнофункциональная работа на платформе VMware vSphere 6. В качестве сервера управления инфраструктурой виртуализации теперь может выступать vCenter Server Appliance (VCSA), а управление ESXi-хостами может осуществляться посредством ESXi Embedded Host Client.
Обновленный продукт осуществляет поддержку управления инфраструктурой на базе Microsoft Hyper-V через System Center Virtual Machine Manager, а управление кластерами Hyper-V реализовано через Failover Cluster Manager.
Для быстрой настройки привилегий пользователей используется ролевая модель доступа. При создании учетной записи можно ограничить доступ по типам объектов, предоставив его, например, только к виртуальным машинам или сетевым объектам.
У продукта появился ряд новых функций для работы в Enterprise-инфраструктурах. Например, реализована поддержка режима горячего резервирования и автопереключение сервера авторизации (High-Availability cluster). В случае потери работоспособности основного сервера в автоматическом режиме происходят переключение на резервный сервер, замена IP-адреса и оповещение администратора.
Обновленная версия продукта позволяет работать с несколькими площадками виртуализации одновременно (этот функционал доступен только в Enterprise-редакции продукта - он будет очень полезен в крупных инфраструктурах). Механизм подключения агента аутентификации к нескольким серверам авторизации vGate дает возможность взаимодействовать со всей территориально распределенной виртуальной инфраструктурой. Построение леса серверов авторизации позволяет устанавливать групповые политики безопасности, а поддержка функции Cross vCenter vMotion обеспечивает в случае аварий миграцию виртуальных машин между серверами с сохранением политик безопасности.
Помимо этого, в vGate версии 3.0 обновлены наборы политик безопасности, обеспечивающие соответствие приказам ФСТЭК России №17 и №21, стандартам СТО БР ИББС, PCI DSS и другие.
Новые версии vGate R2 и vGate-S R2 применимы для защиты конфиденциальной информации и государственной тайны. Продукты прошли инспекционный контроль ФСТЭК России в подтверждение выданных ранее сертификатов соответствия от 28.03.2011 № 2308 и от 12.07.2011 № 2383.
vGate 3.0 можно приобрести в одной из двух редакций: Standard или Enterprise (для которой доступны все функции работы в крупных инфраструктурах). Ниже приведены основные отличия этих изданий:
Получить дополнительную информацию о технических особенностях vGate и направить запрос на получение демо-ключа можно по e-mail: vgateinfo@securitycode.ru. Более подробная информация о решении представлена на странице продукта vGate R2.
Некоторое время назад мы писали про технологическое превью новой версии платформы виртуализации Citrix XenServer "Dundee" Tech Preview 3, а на днях было объявлено о выходе финальной версии Citrix XenServer 7, построенной на ядре Xen 4.6.
Давайте посмотрим на новые возможности XenServer 7:
1. Интеграция с технологиями Microsoft.
Как и всегда, XenServer от Citrix предоставляет новые возможности в этом плане:
Установка драйверов устройств ввода/вывода через Центр обновления Windows. XenServer поддерживает до 1000 ВМ на хосте, поэтому обновление драйверов Windows VM I/O drivers было проблемой до настоящего момента. Теперь же все это можно делать в автоматическом режиме.
Поддержка SMB-хранилищ в качестве общего хранилища (репозитория) для ВМ на XenServer.
Поддержка контейнеров Docker для Windows Server 2016. Ранее Docker поддерживался только для ОС Linux, но теперь добавили и поддержку Windows.
Новый Management Pack для Microsoft System Center Operations Manager (SCOM). Также напомним, что недавно мы писали о Citrix Connector 3.1 for Microsoft SCCM, который теперь поддерживается и работает.
Улучшенная поддержка Active Directory, что позволяет использовать более сложные конфигурации лесов доменов, а также само взаимодействие с каталогом AD работает быстрее.
2. Улучшенная архитектура безопасности платформы.
Совместно с компанией Bitdefender, Citrix разработала интерфейс XenServer Direct Inspect APIs, который позволяет использовать стороннее ПО для защиты гипервизора и виртуальных машин за счет технологии hypervisor memory introspection (HVMI).
На каждый хост ставится отдельный виртуальный модуль в виде ВМ - privileged security appliance (SVA), который контролирует входящий и исходящий поток к виртуальной машине, работая через доступ напрямую к гипервизору.
Ну а Bitdefender - это первый партнер Citrix, который обеспечивает защиту от сетевых угроз. Решение находится пока в стадии Tech Preview.
3. Средства мониторинга собственного состояния (Health Check).
В XenServer 7 была добавлена функциональность самодиагностики в виде Server Status Reports - отчетов, оповещающих о состоянии хост-серверов. Эти отчеты отсылаются на компонент Citrix Insight Services (CIS), который анализирует состояние многих серверов и сигнализирует о неисправностях.
4. Улучшения масштабируемости и производительности.
Здесь можно отметить следующие моменты:
Поддержка до 5 ТБ оперативной памяти на хосте.
Поддержка до 1,5 ТБ оперативной памяти виртуальной машины.
Поддерживает до 288 физических процессоров.
Поддержка до 32 виртуальных процессоров виртуальных машин (vCPU).
Поддержка до 255 VBD (Virtual Block Device) для виртуальной машины на базе технологии Citrix AppDisks.
Поддержка до 4096 VBD (Virtual Block Device) на хост-сервер.
5. Управление хост-серверами XenServer.
Во-первых, появилась возможность запустить SSH-сессию прямо из клиента XenServer:
Во-вторых, средство XenServer Conversion Manager было обновлено и теперь поддерживает пакетную конверсию физических систем на базе последних релизов Windows (включая Windows 10). Также можно переносить виртуальные машины на базе VMware vSphere 6 на XenServer.
В-третьих, расширенная поддержка средств масштабирования позволяет добавлять новые узлы к существующим пулам ресурсов, независимо от типа процессора (при условии, что они одного и того же производителя). Теперь виртуальные машины могут легко мигрировать между пулами.
6. Поддержка ускорения графики средствами Intel GVT Virtual GPU для Windows.
Мы уже много писали про клиент для управления хост-серверами VMware ESXi Embedded Host Client, который поставляется в виде виртуального модуля, доступного на сайте проекта VMware Labs. Начиная с версии VMware vSphere 6.0 Update 2, он вошел в стандартную поставку ESXi (клиент седьмой версии). Но сам Embedded Host Client продолжает также развиваться и как отдельный проект. На днях было выпущено обновление - VMware ESXi Embedded Host Client v8.
Посмотрим на основной список новых возможностей Host Client:
Основное
Таблицы (гриды) теперь с фильтрами/поиском и подсветкой по паттерну поиска.
Большинство таблиц поддерживает контекстное меню по правой кнопке для колонок.
Автоисправление конфигурации прокси, когда обнаруживаются конфликты путей.
Исправления приветственной страницы: нет ошибки JSON Parse error, поддержка директив {ignore}{/ignore} и {accept}Message beside checkbox{/accept} (для того, чтобы заставить пользователя принять условия показываемого при логине сообщения). Делается это в файле /etc/vmware/welcome.
Улучшения отображения интерфейса в разделе производительность: поиск/фильтры, улучшенное отображение линий и т.п.
Хост ESXi
Поддержка опций VSAN maintenance mode.
Фиксы багов Advanced Configuration.
Улучшенное отображение аппаратных сенсоров.
Виртуальные машины
Добавление звуковых контроллеров в ВМ.
Улучшенная валидация при добавлении последовательных портов.
Улучшенный интерфейс для Advanced Settings виртуальной машины.
Пофикшены некоторые проблемы при редактировании настроек ВМ на ESXi 5.0.
Поддержка добавления/удаления пробрасываемых USB-устройств (passthrough). На данный момент это доступно только для включенных машин.
В раздел мониторинга производительности были добавлены подразделы Disk и Network.
Теперь можно импортировать OVA любого размера + мастер стал удобнее и быстрее.
Больше функций по отсылке комбинаций клавиш в гостевую ОС (Ctrl-c, например).
Доступ к меню действий, когда консоль находится в полноэкранном режиме.
Возможность загрузки VMRC-консоли напрямую с хоста ESXi.
Пофикшен баг с отображением представления VM summary, которое запрашивало пароль.
Пофикшен баг при изменении масштаба консоли.
Поддержка португальской клавиатуры.
Отображение полной информации об IP-конфигурации ВМ в summary.
Хранилища
Поддержка конфигурации software iSCSI: Enable/disable, Authentication settings, Advanced configuration, Add/remove port bindings, Add/remove static targets, Add/remove dynamic targets.
Отображение статуса устройства (включая условия ошибок iSCSI) теперь более очевидно - она на иконке в таблице устройств.
Сеть
Возможность изменения MTU для интерфейса VMkernel.
Улучшенная работа с правилами фаервола.
Пофикшен баг с редактированием интерфейсов VMkernel для ESXi 5.5.
Скачать VMware ESXi Embedded Host Client v8 можно по этой ссылке.
Интересный пост написал Duncan Epping о растянутом кластере (Stretched Cluster) Virtual SAN и обработке события изоляции площадки механизмами HA и VSAN. Изложим тут его вкратце.
Как вы знаете, растянутый кластер Virtual SAN состоит из трех компонентов - две площадки с хранилищами VSAN и виртуальными машинами и одна площадка, выступающая как "свидетель" (Witness) и необходимая для принятия решения о том, какая площадка выпала из внешнего мира (то есть с ней нет связи), а какая способна продолжать поддерживать работу виртуальных машин (как в плане хранения, так и в плане исполнения на вычислительных ресурсах хостов).
Таким образом, обычно схема растянутого кластера выглядит так:
Теперь, допустим, на основной площадке (Site 1) произошла авария - и хосты ESXi с виртуальными машинами стали частично или полностью недоступны. При этом теряется ее связь как со второй площадкой (Site 2), так и с компонентом Witness на третьей площадке.
В этом случае происходит следующее:
Хосты площадки Site 1 имеют связь между собой, события внутренней изоляции не происходит, поэтому HA не реагирует на ситуацию.
Однако кластер Virtual SAN понимает, что площадка Site 1 изолирована от Site 2 и Witness (нет кворума), а значит и от внешнего мира, поэтому принимает решение выключить виртуальные машины. Это поведение можно изменить, установив расширенную настройку VSAN.AutoTerminateGhostVm в значение 0 (но делать это не рекомендуется).
На второй площадке (Site 2) происходят выборы нового Master-узла в кластере VMware HA. Этот узел сверяется со списком protectedlist (в нем пока нет машин из Site 1), добавляет новые ВМ туда и берет на себя владение машинами с первого узла, так как теперь есть кворум у второй площадки. Что такое кворум? Это 2 компонента из трех (большинство) в растянутом кластере - сама эта площадка и компонент Witness (они видят связь друг с другом). Таким образом, VMware HA на второй площадке начинает восстановление виртуальных машин первого сайта.
Как VMware HA убеждается, что на первой площадке эти машины выключены? Да никак - просто по дизайну заложено, что кластер Virtual SAN в случае изоляции площадки Site 1 потушит все ее виртуальные машины, поэтому владение этими машинами перейдет ко второй площадке.
Ну и, конечно же, тут нельзя не порекомендовать интереснейший документ VMware vSphere 6.x HA Deepdive, в котором есть все ответы на подобные вопросы.
Таги: VMware, HA, Stretched, Virtual SAN, VSAN, Blogs, vSphere, ESXi
На протяжении нескольких лет от системных администраторов VMware vSphere постоянно поступают жалобы на низкое быстродействие и глючность тонкого клиента управления платформой - vSphere Web Client. Это неудивительно - ведь веб-клиент vSphere построен на базе фреймворка Adobe Flex (пруф), который вобрал в себя все самые "лучшие" стороны флеш-технологии.
Так вот, время флеша похоже истекает - на сайте проекта VMware Labs появилось превью нового клиента vSphere HTML5 Web Client, построенного на базе новых стандартов HTML 5 и Javascript. Напомним, что флеш плох всего лишь в трех аспектах - производительность, стабильность и безопасность, ну а новый клиент призван все это улучшить.
Клиент vSphere HTML5 Web Client пока поддерживается только для VMware vSphere 6 и более поздних версий. Скажем тут на всякий случай, что этот клиент предназначен для управления виртуальной инфраструктурой только через сервисы VMware vCenter. Если вам нужно управлять отдельным хостом, то используйте ESXi Embedded Host Client, который теперь уже поставляется с vSphere 6.0 Update 2 и более поздними версиями платформы виртуализации.
На данный момент технологическое превью умеет делать следующие вещи:
Операции с питанием виртуальных машин (вкл/выкл/приостановка).
Изменение настроек ВМ (CPU, память, виртуальные диски).
Доступ к консоли виртуальных машин.
Страницы информации для хостов и ВМ.
Горячая миграция машин между хостами ESXi (без перемещения хранилищ).
Клонирование машин и создание шаблонов из ВМ.
Создание новой виртуальной машины (пока возможности ограничены).
Различные графики производительности для мониторинга и отслеживания событий (Performance charts, Tasks, Events).
Представления Global Views (последние задачи, алармы и т.п.).
К сожалению, пока в этом клиенте нет функций vSphere Update Manager (напомним, что и в обычном-то vSphere Web Client они появились спустя оочень долгое время).
Скачать VMware vSphere HTML5 Web Client можно в виде готового к развертыванию виртуального модуля OVA по этой ссылке. Для развертывания тонкого клиента понадобится поколдовать с командной строкой (инструкции доступны здесь), ну а в следующих версиях обещают полноценный GUI.
Таги: VMware, vSphere, Labs, Update, Web Client, Performance
В недавно вышедшем обновлении платформы виртуализации VMware vSphere 6.0 Update 2 появилась возможность конфигурации Logon Banner (он же Security Banner) для того, чтобы предупредить пользователей или потенциальных злоумышленников о последствиях неавторизованного доступа к системе. Подробно об особенностях его конфигурации написал Вильям Лам, а мы рассмотрим тут основные моменты настройки баннера вкратце.
Это стандартный подход к обеспечению безопасности, баннер мало кого останавливает, но хотя бы сам факт его наличия будет еще одним пунктиком при привлечении нарушителя к ответственности.
Конфигурация логон-баннера доступна только через интерфейс Platform Services Controller (PSC) Administrator UI, к которому можно получить доступ по следующей ссылке:
https://[PSC-HOSTNAME]/psc
В разделе Configuration вы найдете конфигурацию баннера, где можно настроить следующие параметры:
Status - включен он или выключен.
Checkbox Consent - будет ли показан обязательный для отметки чекбокс согласия с правилами.
Title - заголовок текста.
Message - собственно, само сообщение.
Также можно изменять данные параметры из командной строки с помощью сценария /opt/vmware/bin/sso-config.sh, что требует SSH-доступа к хосту PSC. Ну и вам понадобится создать файл banner.txt, где будет содержаться основной текст баннера безопасности.
Для того, чтобы установить заголовок баннера и его текст, но не включать чекбокс, используйте следующую команду:
opt/vmware/bin/sso-config.sh -set_logon_banner /root/banner.txt -title 'Disclaimer' -enable_checkbox N
Можно не использовать путь к тестовому файлу, а, например, просто изменить заголовок:
Вчера мы писали о новых возможностях, появившихся в обновленной версии платформы виртуализации VMware vSphere 6.0 Update 2, однако не упомянули интересную деталь, которая важна для пользователей в крупных инфраструктурах.
Когда хост VMware ESXi входит в режим обслуживания (Maintenance Mode), происходит следующее: все виртуальные машины на хосте перемещаются ("эвакуируются") на другие хост-серверы ESXi для того, чтобы по окончании процесса временно вывести хост из состава виртуальной инфраструктуры для манипуляций с ним, без остановки сервисов в виртуальных машинах.
Но суть улучшения Update 2 состоит в следующем. До этого релиза сначала происходила миграция запущенных виртуальных машин, которая занимала несколько минут и более, в зависимости от нагрузки на них. Затем уже происходила миграция выключенных машин и шаблонов ВМ (VM Templates), перенести которые занимает несколько секунд (просто перерегистрировать их на других хостах).
Однако при вхождении хоста в Maintenance Mode операции с его объектами (в том числе шаблонами) недоступны, а значит сервисы, задействовавшие клонирование ВМ из шаблона (например, VMware View или vCloud Director), также не могут исполнять свои функции, и пользователям придется ожидать окончания процесса.
Ну а в Update 2 просто поменяли местами порядок переноса - сначала мигрируют выключенные ВМ и шаблоны, что позволяет использовать их уже через несколько секунд, а только потом переезжают включенные виртуальные машины. Это иллюстрируется простой и понятной картинкой:
Компания VMware на днях выпустила множество обновлений своей продуктовой линейки в сфере серверной виртуализации. Прежде всего, важно, что было выпущено обновление VMware Virtual SAN 6.2, о котором мы подробно писали вот тут. Теперь его можно скачать и использовать в производственной среде.
Также для того, чтобы была обеспечена полная поддержка новых возможностей VSAN 6.2 была выпущена обновленная версия платформы виртуализации VMware vSphere 6.0 Update 2. Но самое главное там - это то, что теперь VMware Host Client (который вы знаете как ESXi Embedded Host Client) включен в стандартную поставку ESXi и доступен из коробки!
Напомним также, что о прошлом апдейте vSphere 6 Update 1, который вышел почти полгода назад, мы писали вот тут.
Посмотрим на новые возможности vSphere 6.0 Update 2. Что нового в ESXi 6.0 Update 2:
High Ethernet Link Speed: теперь ESXi 6.0 U2 поддерживает скорости ethernet-соединения 25G и 50G.
VMware Host Client: новый HTML5-клиент для управления одиночным хостом VMware ESXi, о последних версиях которого в виде VMware Fling мы писали вот тут, тут и тут. Это средство для выполнения основных административных задач, управления ресурсами и виртуальными машинами. Также Host Client подходит для поиска и решения проблем, возникших на отдельных хостах VMware ESXi, когда, например, vCenter Server или Web Client недоступны. Смотрите также Host Client 1.0 Release Notes.
vSphere APIs for I/O Filtering (VAIO): ESXi 6.0 Update 2 теперь поддерживает компонент IO Filter VASA Provider в полноценном IPv6-окружении.
Поддержка VMIOF версий 1.0 и 1.1, а также множество исправлений ошибок.
Поддержка двухфакторной аутентификации в vSphere Web Client средствами следующих технологий:
RSA SecurID
Смарт-карты (UPN based Common Access Card)
Поддержка изменения уровня логгирования vSphere ESX Agent Manager без его перезагрузки.
Поддержка vSphere Web Cient для Microsoft Windows 10.
Поддержка новых версий в качестве внешних СУБД VMware vCenter:
Microsoft SQL Server 2012 Service Pack 3
Microsoft SQL Server 2014 Service Pack 1
Помимо всего этого, в последнее время компания VMware выпустила также обновления следующих своих продуктов (о новых возможностях вы можете узнать из соответствующих Release Notes):
Давно мы не публиковали таблицу сравнения изданий VMware vSphere, а ведь в версии vSphere 6.0 много что изменилось, поэтому иногда полезно взглянуть на таблицу ниже. Кроме того, помните, что с 30 июня колонок в таблице станет на одну меньше - издание vSphere Enterprise снимается с продаж.
Возможность / Издание VMware vSphere
Hypervisor 6 (бесплатный ESXi)
vSphere Essentials 6
vSphere Essentials Plus 6
vSphere Standard 6
vSphere Enterprise 6.0 - (снимается с продаж 30 июня 2016 года
Компания VMware выпустила очень интересный документ "VMware vSphere 6
Fault Tolerance
Architecture and Performance", посвященный производительности технологии VMware Fault Tolerance (FT), которая позволяет обеспечивать непрерывную доступность виртуальных машин, даже в случае отказа хост-сервера VMware ESXi. Делается это за счет техники Fast Checkpointing, по своей сути похожей на комбинацию Storage vMotion и vMotion, которая копирует состояние дисков, памяти, процессорных команд и сетевого трафика на резервную машину, поддерживая ее в полностью синхронизированном с первой состоянии. На данный момент vSphere 6 FT поддерживает виртуальные машины с конфигурацией до 4 vCPU и до 64 ГБ оперативной памяти на хост ESXi.
Давайте посмотрим на интереснейшие результаты тестирования производительности, приведенные в документе.
1. Процедура компиляции ядра в гостевой ОС.
Эта процедура грузит CPU на 100%, поэтому посмотрим, каковы тут потери, связанные с аспектами производительности процессора и синхронной передачи команд. Все вполне хорошо, потери небольшие:
2. Сетевая активность.
Если говорить о производительности сетевой коммуникации, то на получение данных потерь практически нет, а вот на передачу все происходит процентов на 10 медленнее. Результат для 1 Гбит сети:
Кстати, очевидно, что сетевой трафик именно самой сети FT максимальный, когда машина принимает много данных (их нужно синхронизировать на второй узел), когда же данные передаются там трафик намного меньше (машина их просто отдает, а синхронизировать нужно только сам процесс передачи и параметры канала).
Результат для 10 Гбит сети. Вот тут и происходит ситуация, когда канал на прием забивается FT-трафиком, как итог - прием происходит только на полосе 2,4 Гбит:
Из-за необходимости поддержки параметров сетевой передачи и приема в синхронном режиме возникает Latency около 6 миллисекунд:
3. Тестирование подсистемы ввода-вывода.
Для тестирования работы с хранилищами (I/O) взяли стандартный инструмент IOMeter. Особых потерь не обнаружилось:
4. Тест Swingbench для Oracle 11g.
Для теста была взята OLTP-нагрузка на базу данных. По числу транзакций в секунду потери небольшие, но задержка по времени ответа возникает значительная:
5. Тест DVD Store на Microsoft SQL Server 2012.
Здесь была запущена симуляция 64 пользовательских сессий. По-сути, этот тест очень похож на методику для Oracle, ну и результаты здесь также соответствующие (но по времени отклика как-то все очень печально):
6. Бенчмарк на базе TPC-E.
Здесь были симулированы операции сервера брокерской компании, который производит обработку OLTP-транзакций в реальном времени. Тест очень стрессовый, и потери здесь весьма существенны:
7. Операции VMware vCenter Server.
Ну а здесь уже сам сервер vCenter защитили технологией Fault Tolerance и измерили производительность операций для двух типов нагрузки - легкой и тяжелой. При тяжелой нагрузке все происходит медленнее больше чем в 2 раза:
vSphere Web Client работает, в общем-то, неплохо, но хотелось бы лучше:
Результаты тестирования очень полезны - теперь администраторы смогут закладывать потери производительности на поддержание FT-кластера в архитектуру планируемой инфраструктуры для бизнес-критичных приложений.
Не так давно на сайте VMwareArena появилось очередное сравнение VMware vSphere (в издании Enterprise Plus) и Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition, которое включает в себя самую актуальную информацию о возможностях обеих платформ.
Мы адаптировали это сравнение в виде таблицы и представляем вашему вниманию ниже:
Группа возможностей
Возможность
VMware vSphere 6
Enterprise Plus
Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition
Возможности гипервизора
Версия гипервизора
VMware ESXi 6.0
Hyper-V 2012 R2
Максимальное число запущенных виртуальных машин
1024
1024
Максимальное число процессоров (CPU) на хост-сервер
480
320
Число ядер на процессор хоста
Не ограничено
Не ограничено
Максимальное число виртуальных процессоров (vCPU) на хост-сервер
4096
2048
Максимальный объем памяти (RAM) на хост-сервер
6 ТБ
4 ТБ
Техники Memory overcommitment (динамическое перераспределение памяти между машинами)
Memory ballooning
Dynamic Memory
Техники дедупликации страниц памяти
Transparent page sharing
Нет
Поддержка больших страниц памяти (Large Memory Pages)
Да
Да
Управление платформой
Централизованное управление
vCenter Server + vSphere Client + vSphere Web Client, а также виртуальный модуль vCenter Server Appliance (vCSA)
System Center Virtual Machine Manager (SC VMM)
Интеграция с Active Directory
Да, как для vCenter, так и для ESXi-хостов через расширенный механизм SSO
Да (через SC VMM)
Поддержка снапшотов (VM Snapshot)
Да, снапшоты могут быть сделаны и удалены для работающих виртуальных машин
Да, технология Checkpoint, включая функции live export
Управление через браузер (тонкий клиент)
Да, полнофункциональный vSphere Web Client
Ограниченное, через Self Service Portal
Обновления хост-серверов / гипервизора
Да, через VMware Update Manager (VUM), Auto Deploy и CLI
Да - Cluster Aware Updates, Fabric Updates, Management Servers
Управление сторонними гипервизорами
Да, бесплатный аддон Multi-Hypervisor Manager
Да, управление VMware vCenter и Citrix XenCenter поддерживается в SC VMM
Обновление (патчинг) виртуальных машин
Да, через VMware Update Manager (VUM) и vCenter Configuration Manager (vCM)
Да (WSUS, SCCM, VMST)
Режим обслуживания (Maintenance Mode)
Да, горячая миграция ВМ в кластере DRS на другие хосты
Да
Динамическое управление питанием
Да, функции Distributed Power Management в составе DRS
Да, функции Power Optimization в составе Dynamic Optimization
API для решений резервного копирования
Да, vStorage API for Data Protection
Да, VSS API
Шаблоны виртуальных машин (VM Templates)
Да + Multi-site content library
Да, включая шаблоны Gen2
Профили настройки хостов (Host Profiles)
Да, расширенные функции host profiles и интеграция с Auto Deploy
Да, функции Physical Computer Profiles
Решение по миграции физических серверов в виртуальные машины
Да, VMware vCenter Converter
Нет, больше не поддерживается
Горячая миграция виртуальных машин
Да, vMotion между хостами, между датацентрами с разными vCenter, Long Distance vMotion (100 ms RTT), возможна без общего хранилища
Да, возможна без общего хранилища (Shared Nothing), поддержка компрессии и SMB3, неограниченное число одновременных миграций
Горячая миграция хранилищ ВМ
Да, Storage vMotion, возможность указать размещение отдельных виртуальных дисков машины
Да
Профили хранилищ
Да, Storage policy-based management
Да, Storage Classifications
Кластер непрерывной доступности ВМ
Да, Fault Tolerance с поддержкой до 4 процессоров ВМ, поддержка различных типов дисков, технология vLockstep
Нет
Конфигурации виртуальных машин
Виртуальных процессоров на ВМ
128 vCPU
64 vCPU
Память на одну ВМ
4 ТБ
1 ТБ
Последовательных портов (serial ports)
32
Только присоединение к named pipes
Поддержка USB
До 20 на одну машину (версии 1,2 и 3)
Нет (за исключением Enhanced Session Mode)
Горячее добавление устройств
(CPU/Memory/Disk/NIC/PCIe SSD)
Только диск и память (память только, если настроена функция Dynamic memory)
Диски, растущие по мере наполнения данными (thin provisioning)
Да (thin disk и se sparse)
Да, Dynamic disks
Поддержка Boot from USB
Да
Нет
Хранилища на базе локальных дисков серверов
VMware Virtual SAN 6.0 с поддержкой конфигураций All Flash
Storage Spaces, Tiered Storage
Уровни обслуживания для подсистемы ввода-вывода
Да, Storage IO Control (работает и для NFS)
Да, Storage QoS
Поддержка NPIV
Да (для RDM-устройств)
Да (Virtual Fibre Channel)
Поддержка доступа по нескольким путям (multipathing)
Да, включая расширенную поддержку статусов APD и PDL
Да (DSM и SMB Multichannel)
Техники кэширования
Да, vSphere Flash Read Cache
Да, CSV Cache
API для интеграции с хранилищами
Да, широкий спектр VASA+VAAI+VAMP
Да, SMI-S / SMP, ODX, Trim
Поддержка NIC Teaming
Да, до 32 адаптеров
Да
Поддержка Private VLAN
Да
Да
Поддержка Jumbo Frames
Да
Да
Поддержка Network QoS
Да, NetIOC (Network IO Control), DSCP
Да
Поддержка IPv6
Да
Да
Мониторинг трафика
Да, Port mirroring
Да, Port mirroring
Подводя итог, скажем, что нужно смотреть не только на состав функций той или иной платформы виртуализации, но и необходимо изучить, как именно эти функции реализованы, так как не всегда реализация какой-то возможности позволит вам использовать ее в производственной среде ввиду различных ограничений. Кроме того, обязательно нужно смотреть, какие функции предоставляются другими продуктами от данного вендора, и способны ли они дополнить отсутствующие возможности (а также сколько это стоит). В общем, как всегда - дьявол в деталях.
Таги: VMware, vSphere, Hyper-V, Microsoft, Сравнение, ESXi, Windows, Server
Компания VMware выпустила первое после нового года обновление своей серверной платформы виртуализации - VMware vSphere 6.0 Update 1b, включая обновления vCenter и ESXi.
Новых возможностей, конечно же, немного, но все же компоненты vSphere рекомендуется обновить ввиду наличия критичных обновлений подсистемы безопасности.
Что нового в VMware vCenter Server 6.0 Update 1b:
Поддержка метода обновления URL-based patching с использованием zip-пакета. Подробнее в KB 2142009.
Пользовательские настройки для Client Integration Plugin или диалогового окна VMware-csd guard в vSphere Web Client могут быть переопределены. Подробнее в KB 2142218.
vSphere 6.0 Update 1b включает поддержку TLS версий 1.1 и 1.2 для большинства компонентов vSphere без нарушения совместимости с предыдущими версиями. Компоненты которые по-прежнему поддерживают только TLS версии 1.0:
vSphere Client
Virtual SAN Observer на сервере vCenter Server Appliance (vCSA)
Syslog на сервере vCSA
Auto Deploy на vCSA
Auto Deploy на iPXE
О поддержке TLS-протоколов можно почитать подробнее в KB 2136185 .
Утилита certificate manager теперь автоматически вызывает скрипт updateExtensionCertInVC.py для обновления хранилищ сертификатов, которые построены не на базе VMware Endpoint Certificate Store (VECS).
Множество исправлений ошибок.
Что нового в VMware ESXi 6.0 Update 1b:
Поддержка TLS версий 1.1 и 1.2 для большинства компонентов без нарушения совместимости с предыдущими версиями.
Поддержка Advanced Encryption Standard (AES) с длиной ключа 128/256 бит для аутентификации через NFS 4.1 Client.
Исправления ошибок.
Скачать VMware vCenter Server 6.0 Update 1b и VMware ESXi 6.0 Update 1b можно по этой ссылке.
Недавно мы писали о новой функции решения vGate 3.0 for Hyper-V, предназначенного для защиты виртуальной инфраструктуры Microsoft от несанкционированного доступа и безопасной ее конфигурации средствами политик безопасности. В преддверии выхода vGate 3.0 для обеих платформ виртуализации, vSphere и Hyper-V, мы расскажем о некоторых новых функциях продукта, которые будут доступны в обоих изданиях в первом квартале 2016 года.
Как вы знаете, некоторое время назад вышло обновление платформы виртуализации VMware vSphere 6 Update 1, в котором были, в основном, только минорные обновления. Но было и важное - теперь виртуальный модуль VMware vCenter Server Appliance (vCSA) стало возможно обновлять путем монтирования к нему ISO-образа с апдейтом.
Давайте покажем упрощенный процесс обновления через смонтированный образ. Итак, соединимся с хостом vCSA по SSH (если у вас есть отдельный сервер Platform Services Controller, то коннектиться нужно к нему):
Далее скачаем обновление vCenter, в котором есть и обновление vCSA версии 6.0.0 (выберите продукт VC и в разделе VC-6.0.0U1-Appliance скачайтеVMware-vCenter-Server-Appliance-6.0.0.10000-3018521-patch-FP.iso):
Здесь надо пояснить, что это за обновления:
FP (Full patch) - это обновление всех компонентов vCenter, включая полноценные продукты, vCenter, vCSA, VMware Update Manager, PSC и прочее.
TP (Third party patch) - это обновление только отдельных компонентов vCenter.
Скачиваем патч FP (VMware-vCenter-Server-Appliance-6.0.0.10000-3018521-patch-FP.iso), после чего монтируем этот ISO-образ к виртуальной машине vCSA через vSphere Web Client или Embedded Host Client.
Далее возвращаемся к консоли vCSA:
Смонтировать ISO-образ можно также через PowerCLI с помощью следующих команд:
Далее выполняем следующую команду, если вы хотите накатить патчи прямо сейчас:
software-packages install --iso --acceptEulas
Либо патчи можно отправить на стейджинг отстаиваться (то есть пока обновить компоненты, но не устанавливать). Сначала выполняем команду отсылки на стейджинг:
software-packages install --iso --acceptEulas
Далее просматриваем содержимое пакетов:
software-packages list --staged
И устанавливаем апдейт со стейджинга:
software-packages install --staged
Если во время обновления на стейджинг или установки обновления возникли проблемы, вы можете просмотреть логи, выполнив следующие команды:
shell.set –enabled True shell cd /var/log/vmware/applmgmt/ tail software-packaged.log –n 25
Далее размонтируйте ISO-образ от виртуальной машины или сделайте это через PowerCLI следующей командой:
shutdown reboot -r "Updated to vCenter Server 6.0 Update 1"
Теперь откройте веб-консоль vCSA по адресу:
https://<FQDN-or-IP>:5480
И перейдите в раздел Update, где вы можете увидеть актуальную версию продукта:
Кстати, обратите внимание, что возможность проверки обновления в репозитории (Check URL) вернулась, и обновлять vCSA можно прямо отсюда по кнопке "Check Updates".
Для тех из вас, кто еще не обновил свою инфраструктуру на последнюю версию VMware vSphere 6, компания VMware приготовила очередной пакет исправлений VMware vSphere 5.5 Update 3b. На самом деле, это просто патч VMware ESXi 5.5 patch ESXi550-201512001, в котором произошли некоторые изменения в плане безопасности, а также исправлены ошибки.
Среди заявленных фич, касающихся security, основная - это отключенный по умолчанию SSL третьей версии (SSLv3). Отключили его (как в клиенте, так и в сервере) потому, что он считается устаревшим, и его поддержка уже не предоставляется в большинстве Enterprise-продуктов (об этом можно почитать в RFC 7568).
Внимание! Обязательно следуйте рекомендованной последовательности обновления продуктов VMware, то есть сначала обновите vCenter до версии 5.5 Update 3b и только потом ESXi 5.5 до версии Update 3b, чтобы избежать проблем с отключением хостов от сервера управления vCenter.
Также помните, что VMware View Composer версии ниже 6.2 не будет работать с хостами ESXi 5.5 Update 3b.
На блогах VMware появился интересный пост про производительность виртуальных машин, которые "растянуты" по ресурсам на весь физический сервер, на котором они запущены. В частности, в посте речь идет о сервере баз данных, от которого требуется максимальная производительность в числе транзакций в секунду (см. наш похожий пост о производительности облачного MS SQL здесь).
В данном случае речь идет о виртуализации БД с типом нагрузки OLTP, то есть обработка небольших транзакций в реальном времени. Для тестирования использовался профиль Order-Entry, который основан на базе бенчмарка TPC-C. Результаты подробно описаны в открытом документе "Virtualizing Performance Critical Database Applications in VMware vSphere 6.0", а здесь мы приведем основные выдержки.
Сводная таблица потерь на виртуализацию:
Метрика
Нативное исполнение нагрузки
Виртуальная машина
Пропускная способность транзакций в секунду
66.5K
59.5K
Средняя загрузка логических процессоров (72 штуки)
84.7%
85.1%
Число операций ввода-вывода (Disk IOPS)
173K
155K
Пропускная способность ввода-вывода дисковой подсистемы (Disk Megabytes/second)
929MB/s
831MB/s
Передача пакетов по сети в секунду
71K/s receive
71K/s send
63K/s receive
64K/s send
Пропускная способность сети в секунду
15MB/s receive
36MB/s send
13MB/s receive
32MB/s send
А вот так выглядит график итогового тестирования (кликабельно):
Для платформы VMware ESXi 5.1 сравнивалась производительность на процессоре микроархитектуры Westmere, а для ESXi 6.0 - на процессорах Haswell.
Результаты, выраженные в числе транзакций в секунду, вы видите на картинке. Интересно заметить, что ESXi версии 6.0 всерьез прибавил по сравнению с прошлой версией в плане уменьшения потерь на накладные расходы на виртуализацию.
А вот так выглядят усредненные значения для версий ESXi в сравнении друг с другом по отношению к запуску нагрузки на нативной платформе:
Ну и несложно догадаться, что исследуемая база данных - это Oracle. Остальное читайте в интереснейшем документе.
Странные вещи происходят в последнее время с VMware. Сначала в технологии Changed Block Tracking (CBT) платформы VMware vSphere 6 был найдет серьезный баг, заключавшийся в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Из-за этого пользователи переполошились не на шутку, ведь бэкапы, а это критически важная составляющая инфраструктуры, могли оказаться невосстановимыми.
Недавно этот баг был пофикшен в обновлении ESXi600-201511401-BG, и вроде бы все стало окей. Но нет - оказалось, что накатить обновление на ваши серверы VMware ESXi недостаточно, о чем своевременно сообщила компания Veeam (официальная KB находится вот тут). Нужно еще и сделать операцию "CBT reset", то есть реинициализировать Changed Block Tracking для виртуальных машин.
Все дело в том, что уже созданные файлы CBT map могут содержать невалидные данные, касательно изменившихся блоков, а ведь они могли быть созданы еще до накатывания патча от VMware. Таким образом, простое обновление ESXi не убирает потенциальную проблему - старые файлы *-ctk.vmdk могут, по-прежнему, быть источником проблем. Удивительно, как такая могучая компания как VMware просто взяла и прошляпила этот момент.
Итак, как нужно делать CBT reset для виртуальной машины описано вот тут у Veeam. Приведем этот процесс вкратце:
1. Открываем настройки виртуальной машины (да-да, для каждой ВМ придется это делать) и идем в Configuration Parameters:
2. Там устанавливаем значение параметра:
ctkEnabled = false
3. Далее устанавливаем
scsi0:x.ctkEnabled также в значение false:
4. Открываем папку с виртуальной машиной через Datastore Browser и удаляем все файлы *-ctk.vmdk (это и есть CBT map файлы):
5. Включаем виртуальную машину и заново запускаем задачу резервного копирования Veeam Backup and Replication.
Для тех, кто умеет пользоваться интерфейсом PowerCLI есть бонус - компания Veeam сделала PowerShell-скрипт, который автоматизирует эту операцию. Он позволяет переинициализировать CBT для указанных пользователем виртуальных машин. Виртуальные машины со снапшотом, а также выключенные ВМ будут проигнорированы. Также надо отметить, что при выполнении сценария создается снапшот машины, а потом удаляется, что может вызвать временное "подвисание" машины и ее недоступность в течение некоторого времени, поэтому лучше выполнять этот скрипт ночью или в нерабочие часы.
Некоторое время назад мы писали об очень серьезном баге в технологии Changed Block Tracking, обеспечивающей работу инкрементального резервного копирования виртуальных машин VMware vSphere 6. Баг заключался в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывала потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап был неконсистентным.
Мы писали про временное решение, заключающееся в отключении технологии CBT при снятии резервных копий продуктом Veeam Backup and Replication, но оно, конечно же, было неприемлемым, так как скорость бэкапов снижалась в разы, расширяя окно резервного копирования до неприличных значений.
И вот, наконец, вышло исправление этого бага, описанное в KB 2137545. Это патч для сервера VMware ESXi, который распространяется в виде стандартного VIB-пакета в сжатом zip-архиве.
Чтобы скачать патч, идите по этой ссылке, выберите продукт "ESXi Embedded and Installable" и введите в поле Enter Bulletin Number следующую строчку:
ESXi600-201511401-BG
Нажмите Search, после чего скачайте обновленный билд VMware ESXi 6.0 по кнопке Download:
Про патч в формате VIB-пакета написано вот тут, а про сам обновленный релиз ESXi вот тут. Для установки VIB на сервере ESXi используйте следующую команду:
Недавно мы писали о серьезном баге в механизме Changed Block Tracking (CBT) платформы VMware vSphere 6, который приводит к тому, что инкрементальные резервные копии виртуальных машин оказываются невосстановимыми.
Это, конечно, очень неприятное известие, но не для пользователей решения Veeam Backup and Replication, так как там есть возможность отключить поддержку глючной технологии CBT. Для этого идем в свойства задачи резервного копирования (Edit Backup Job) и выбираем там пункт "Advanced":
И на вкладке vSphere расширенных настроек убираем галку "Use changed block tracking data (recommended)":
Это приведет к тому, что при создании инкрементальных резервных копий Veeam B&R при следующем запуске задачи не будет использовать технологию CBT для отслеживания изменившихся блоков, а значит при создании инкремента бэкапа будут сравниваться все блоки диска ВМ на отличия от бэкапа. Это займет большее время, но ваша резервная копия гарантированно окажется восстановимой.
Такое вот приятное отличие Veeam Backup and Replication от других продуктов для резервного копирования позволит вам продолжать использовать технологии резервного копирования в производственной среде в то время как все остальные пользователи (которые без B&R) страдают и воют от безысходности.
На сайте проекта VMware Labs, где сотрудники VMware частенько публикуют различного рода утилиты для инфраструктуры VMware vSphere, появилось обновление очень полезной штуки, которое все очень давно ждали - VMware Auto Deploy GUI. Напомним, что о прошлой верcии этого средства мы писали вот тут.
Теперь вы можете проводить преднастройку профилей и развертывание новых хостов VMware ESXi 6 для Stateless-окружения прямо из графического интерфейса VMware vSphere Client:
Auto Deploy GUI - это плагин к vSphere Client, реализующий основные функции VMware vSphere Auto Deploy, такие как:
Создание/редактирование правил соответствия хостов и профилей образов.
Проверка соответствия хостов этим правилам и восстановление этого соответствия.
Новые возможности последней версии Auto Deploy GUI:
Поддержка VMware vSphere 6.0.
В мастере Image Profile Wizard появились новые функции "VIB filter".
Новые средства "PXE Host List and Boot Configuration troubleshooting" для решения проблем с загрузкой хостов.
Надо отметить, что это последняя версия Auto Deploy GUI, которая поддерживает VMware vSphere версии 5.0. Скачать VMware Auto Deploy GUI можно по этой ссылке. Ну и порекомендуем очень полезный документ "VMware Auto Deploy GUI Practical Guide".
Как-то раз мы писали про баг в VMware vSphere 5.5 (и более ранних версиях), заключавшийся в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT) их резервные копии оказывались невалидными и не подлежащими восстановлению. Эта ошибка была через некоторое время пофикшена.
Суть критического бага в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могут быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывает потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап будет неконсистентным. То есть баг намного более серьезный, чем был в версии vSphere 5.5 (там надо были задеты только ВМ, диски которых увеличивали, а тут любая ВМ подвержена багу).
На данный момент решения этой проблемы нет, надо ждать исправления ошибки. Пока VMware предлагает на выбор 3 варианта:
Сделать даунгрейд хостов ESXi на версию 5.5, а версию virtual hardware 11 понизить на 10.
Делать полные бэкапы виртуальных машин (full backups) вместо инкрементальных.
Выключать виртуальные машины во время инкрементального бэкапа, чтобы у них не было никаких IO, которые могут потеряться.
Как вы понимаете, ни один из этих вариантов неприемлем в условиях нормальной работы производственной среды. Мы оповестим вас об исправлении ошибки, ну а пока поздравляем службу контроля качества компании VMware с очередной лажей!
P.S. Пока делайте полные бэкапы критичных систем. И следите за новостями от Veeam.
3 года назад мы писали об утилите ESXi5 Community Packaging Tools 2.0, которая позволяет создавать собственные пакеты для VMware ESXi в форматах VIB (VMware Installation Bundle) and ZIP (VMware Offline Bundle). В результате VIB-файлы получают уровень доверия (acceptance level) Community Supported. Зачастую, эти утилиты необходимы пользователям для включения сторонних драйверов устройств в состав дистрибутива платформы ESXi, которые отсутствуют в стандартном комплекте поставки.
На самом деле, изменений было сделано не так много, но они есть и важные:
Появилась полная поддержка VMware vSphere 6 (именно поэтому "ESXi5 Community Packaging Tools" (ESXi5-CPT) переименованы в "ESXi Community Packaging Tools" (ESXi-CPT).
Пакетный сценарий TGZ2VIB5.cmd обновлен до версии 2.3.
Пофикшено название уровня доверия (acceptance level) "certified" (раньше он назывался "vmware").
Добавлены пресеты конфигураций "ESXi 6.0+ driver" и "VMware Tools" (tools-light.vib). Теперь вы можете создать свой пакет VMware Tools для распространения в гостевых ОС на базе гипервизора ESXi!
Добавлена поддержка типа VIB-пакета (vibType) "locker".
Пакетный файл VIB2ZIP.cmd обновился до версии 1.3 - туда были добавлен выбор настроек совместимости для VMware ESXi.
Видео о создани VMware Offline Bundle с помощью VIB2ZIP:
Скачать ESXi Community Packaging Tools версии 2.3 можно по этой ссылке.
Некоторое время назад вышло обновление VMware vSphere 6.0 Update 1, после чего пользователи Onyx под Web Client заметили, что он перестал работать. Напомним, что Onyx предназначен для записи действий пользователя в клиенте vSphere, после чего они записываются в виде сценариев PowerShell.
Теперь в обновленном Onyx для VMware vSphere Web Client, который можно скачать с сайта VMware Labs, новая версия vSphere 6.0 U1 полностью поддерживается.
Причина плохого поведения Onyx проста - так как этот продукт теперь полностью завязан на VMware vCenter, то теперь любое значимое изменение оного требует отдельного апдейта.
Таги: VMware, Onyx, Update, Labs, vSphere, Web Client, PowerShell, PowerCLI
Мы уже не раз писали про VMware ESXi Embedded Host Client, который возвращает полноценный веб-клиент для сервера VMware ESXi с возможностями управления хостом и виртуальными машинами, а также средствами мониторинга производительности.
Теперь для этого продукте есть offline bundle, который можно накатывать с помощью VMware Update Manager, как на VMware vSphere 5.x, так и на VMware vSphere 6.x.
Одна из долгожданных фичей этого релиза - возможность просматривать и редактировать разделы дисков ESXi:
Если у вас есть это средство второй версии, то обновиться на третью можно с помощью следующей команды:
Интересная возможность есть в VMware vSphere 6, которая может оказаться полезной для администраторов датацентров, которые имеют подчиненность главному ЦОД, который задает стандарты администрирования виртуальной инфраструктуры. Возьмем, например, РЖД - у них есть главный вычислительный центр (ГВЦ) и сеть информационно-вычислительных центров (ИВЦ) по всей стране, в которых, как и в ГВЦ, есть свои виртуальные инфраструктуры на платформе VMware vSphere.
Так вот, функция VMware vSphere Content Library позволяет подписать ИВЦ на обновления ГВЦ (который будет издатель/publisher), где можно создать шаблон виртуальной машины, а на уровне ИВЦ (подписчик/subscriber) администраторы этот шаблон ВМ увидят и установят. Очень удобно.
Для этого в центральном датацентре нужно перейти в раздел Content Libraries в vSphere Web Client:
Там нажимаем иконку создания нового объекта и добавляем новую библиотеку (Library):
Далее возьмем виртуальную машину, которую мы хотим превратить в шаблон (VM Template) и выберем из ее контекстного меню пункт Clone -> Clone to Template in Library:
Переходим на вкладку Related Objects и убеждаемся, что шаблон виртуальной машины добавлен в библиотеку:
Теперь, чтобы опубликовать библиотеку (Publish), нужно пойти на вкладку Manage, нажать Edit и поставить галку Publish this library externally (можно задать параметры доступа в разделе Authentication):
Уже в региональном датацентре нужно создать новую библиотеку:
И выбрать пункт Subscribed content library, указав URL центральной библиотеки паблишера:
После этого мы увидим в ней шаблон виртуальной машины, который мы создали в центральном датацентре:
Ну и из этого шаблона мы можем развернуть новую виртуальную машину в нашем региональном ЦОД на базе стандартов центра:
Как вы наверное заметили, помимо вкладки Templates, есть еще и вкладка Other Types, то есть можно публиковать не только шаблоны, но и другие объекты. Наиболее полезно будет распространять таким способом ISO-образы для гостевых ОС, а также скрипты для автоматизации различного рода операций. Удобная штука, но мало кто об этом знает.
После выхода новой версии платформы VMware vSphere 6 перед многими администраторами встал вопрос об обновлении различных компонентов виртуальной инфраструктуры. На крупных предприятиях, как правило, используется не только платформа VMware ESXi и сервисы управления vCenter, но и различные корпоративные продукты, такие как VMware Horizon View для инфраструктуры виртуальных ПК или VMware vRealize Operations (vROPs) для мониторинга и решения проблем.
Вот в какой правильной последовательности нужно обновлять решения VMware (если у нескольких продуктов очередь одна - их можно обновлять в любой последовательности):
Продукт
VMware
Последовательность обновления (очередность)
vCenter
Single Sign-On (SSO)
1
vRealize Automation (vRA), бывший vCloud Automation Center
2
vRealize Configuration Manager (VCM), бывший vCenter Configuration Manager
2
vRealize Business (он же ITBM - VMware IT Business Management)
2
vRealize Automation Application Services (vRAS), бывший vSphere AppDirector
3
vCloud Director (vCD)
3
vCloud Networking and Security (vCNS)
4
NSX Manager
4
NSX Controllers
5
View Composer
5
View Connection Server
6
vCenter Server
7
vRealize Orchestrator (vRO), он же vCenter Orchestrator
8
vSphere Replication (VR)
8
vCenter Update Manager (VUM)
8
vRealize Operations Manager (vROPs) / он же vCenter Operations Manager (vCOPs)
8
vSphere Data Protection (VDP)
8
vCenter Hyperic
8
vCenter Infrastructure Navigator (VIN)
8
vCloud Connector (vCC)
9
vRealize Log Insight (vRLI)
9
vSphere Big Data Extension (BDE)
9
vCenter Site Recovery Manager (SRM)
9
ESXi
10
VMware Tools
11
vShield / NSX / Edge
11
vShield App/ NSX LFw
12
vShield Endpoint / NSX Guest IDS
12
View Agent / Client
12
О проведении операций по обновлению компонентов решений VMware более подробно рассказано в статье KB 2109760. Там же приведены примеры сценариев обновления, если у вас есть определенный набор продуктов.
Кстати, помните, что после обновления на VMware vSphere 6.0 вы не сможете использовать продукт VMware Storage Appliance, который больше не поддерживается.
Иногда администраторам хранилищ в VMware vSphere требуется передать логический том LUN или локальный диск сервера под другие цели (например, отдать не под виртуальные системы или передать в другой сегмент виртуальной инфраструктуры). В этом случае необходимо убедиться, что все данные на этом LUN удалены и не могут быть использованы во вред компании.
Раньше это приходилось выполнять путем загрузки из какого-нибудь Linux LiveCD, которому презентован данный том, и там удалять его данные и разделы. А в VMware vSphere 6 Update 1 появился более простой способ - теперь эта процедура доступна из графического интерфейса vSphere Web Client в разделе Manage->Storage Adapters:
Теперь просто выбираем нужный адаптер подсистемы хранения и нажимаем Erase для удаления логических томов устройства (будут удалены все логические тома данного устройства):
Теперь можно использовать этот локальный диск по другому назначению, например, отдать кластеру VSAN.
Ну и также отметим, что в следующей версии утилиты ESXi Embedded Host Client компания VMware сделает возможность не только удаления таблицы разделов, но и добавит средства их редактирования:
Как вы знаете, некоторое время назад компания VMware выпустила обновление платформы виртуализации vSphere 6 Update 1. После его выхода компания Veeam предупредила пользователей, что средство резервного копирования виртуальных машин Veeam Backup & Replication 8.0 пока не поддерживает последнее обновление от VMware. И вот на днях вышел Veeam Backup & Replication 8.0 Update 3с полной поддержкой vSphere 6 Update 1. Так что большинство пользователей платформы ESXi может смело обновлять свою инфраструктуру.
Посмотрим на все новые возможности последнего обновления Veeam B&R:
Улучшения для Microsoft Windows:
Поддержка Windows 10 в качестве гостевой ОС (включая обработку приложений - application-aware processing).
Поддержка установки Veeam Backup & Replication и всех его компонентов на Windows 10.
Улучшения для VMware vSphere:
Поддержка vSphere 6.0 Update 1.
Возможность превратить предупреждение "VMware Tools not found" в информационное сообщение. Для этого параметр DisableVMwareToolsNotFoundWarning (REG_DWORD) в реестре нужно установить в значение 1.
Улучшения для Linux:
Поддержка SSH-шифрования: aes128-ctr, aes192-ctr, aes256-ctr, aes192-cbc и aes256-cbc.
Новое у Veeam Explorer for Microsoft SQL Server:
Лог транзакций для неподдерживаемых экземпляров SQL Server автоматически игнорируется, чтобы избежать сообщений об ошибке.
Предпочитаемые сетевые настройки также применяются к задачам бэкапа транзакционного лога.
Новое у Veeam Explorer for SharePoint:
Поддержка аутентификации ADFS
Поддержка UPN credentials.
Улучшения SureBackup
Модуль Proxy appliance теперь отвечает на пинг внутри виртуальной лаборатории (Virtual Lab), чтобы сетевые экраны не блокировали автоматически ее сеть как публичную.
Другое:
Улучшено шифрование.
Улучшена производительность операций консоли в больших окружениях.
Уменьшена нагрузка на сервер SQL, а также увеличена надежность.
Увеличена производительность настройки конфигурации резервного копирования для больших окружений.
Прочие исправления ошибок в различных областях.
Скачать Veeam Backup & Replication 8.0 Update 3 можно по этой ссылке (нужно залогиниться).
Спустя весьма продолжительное время с момента релиза новой версии платформы vSphere 6.0, компания VMware выпустила обновленную версию статьи базы знаний KB 2131180, в которой приведена схема со всеми портами и соединениями, используемыми в виртуальной инфраструктуре.
Штука это очень полезная и прямо просится на стенку в виде плаката в помещение, где сидят администраторы VMware vSphere. На страницах с 3 по 9 находится таблица со всеми соединениями, где указаны номера портов, протокол, источник и целевой компонент, а также назначение соединения.
Недавно Cormac Hogan написал интересный пост о том, как нужно настраивать "растянутый" между двумя площадками HA-кластер на платформе VMware vSphere, которая использует отказоустойчивую архитектуру Virtual SAN.
Напомним, как это должно выглядеть (два сайта на разнесенных площадках и witness-хост, который обрабатывает ситуации разделения площадок):
Основная идея такой конфигурации в том, что при отказе отдельного хоста или его компонентов виртуальная машина обязательно должна запуститься на той же площадке, где и была до этого, а в случае отказа всей площадки (аварии) - машины должны быть автоматически запущены на резервном сайте.
Откроем настройки кластера HA. Во-первых, он должен быть включен (Turn on vSphere HA), и средства обнаружения сетевых отказов кластера (Host Monitoring) также должны быть включены:
Host Monitoring позволяет хостам кластера обмениваться сигналами доступности (heartbeats) и в случае отказа предпринимать определенные действия с виртуальными машинами отказавшего хоста.
Для того, чтобы виртуальная машина всегда находилась на своей площадке в случае отказа хоста (и использовала локальные копии данных на виртуальных дисках VMDK), нужно создать Affinity Rules, которые определяют правила перезапуска ВМ на определенных группах хостов в рамках соответствующей площадки. При этом эти правила должны быть "Soft" (так называемые should rules), то есть они будут соблюдаться при возможности, но при отказе всей площадки они будут нарушены, чтобы запустить машины на резервном сайте.
Далее переходим к настройке "Host Hardware Monitoring - VM Component Protection":
На данный момент кластер VSAN не поддерживает VMCP (VM Component Protection), поэтому данную настройку надо оставить выключенной. Напомним, что VMCP - это новая функция VMware vSphere 6.0, которая позволяет восстанавливать виртуальные машины на хранилищах, которые попали в состояние All Paths Down (APD) или Permanent Device Loss (PDL). Соответственно, все что касается APD и PDL будет выставлено в Disabled:
Теперь посмотрим на картинку выше - следующей опцией идет Virtual Machine Monitoring - механизм, перезапускающий виртуальную машину в случае отсутствия сигналов от VMware Tools. Ее можно использовать или нет по вашему усмотрению - оба варианта полностью поддерживаются.
На этой же кариинке мы видим настройки Host Isolation и Responce for Host Isolation - это действие, которое будет предпринято в случае, если хост обнаруживает себя изолированным от основной сети управления. Тут VMware однозначно рекомендует выставить действие "Power off and restart VMs", чтобы в случае отделения хоста от основной сети он самостоятельно погасил виртуальные машины, а мастер-хост кластера HA дал команду на ее восстановление на одном из полноценных хостов.
Далее идут настройки Admission Control:
Здесь VMware настоятельно рекомендует использовать Admission Control по простой причине - для растянутых кластеров характерно требование самого высокого уровня доступности (для этого он, как правило, и создается), поэтому логично гарантировать ресурсы для запуска виртуальных машин в случае отказа всей площадки. То есть правильно было бы зарезервировать 50% ресурсов по памяти и процессору. Но можно и не гарантировать прям все 100% ресурсов в случае сбоя, поэтому можно здесь поставить 30-50%, в зависимости от требований и условий работы ваших рабочих нагрузок в виртуальных машинах.
Далее идет настройка Datastore for Heartbeating:
Тут все просто - кластер Virtual SAN не поддерживает использование Datastore for Heartbeating, но такого варианта тут нет :) Поэтому надо выставить вариант "Use datastores only from the secified list" и ничего из списка не выбирать (убедиться, что ничего не выбрано). В этом случае вы получите сообщение "number of vSphere HA heartbeat datastore for this host is 0, which is less than required:2".
Убрать его можно по инструкции в KB 2004739, установив расширенную настройку кластера das.ignoreInsufficientHbDatastore = true.
Далее нужно обязательно установить кое-какие Advanced Options. Так как кластер у нас растянутый, то для обнаружения наступления события изоляции нужно использовать как минимум 2 адреса - по одному на каждой площадке, поэтому расширенная настройка das.usedefaultisolationaddress должна быть установлена в значение false. Ну и нужно добавить IP-адреса хостов, которые будут пинговаться на наступление изоляции хост-серверов VMware ESXi - это настройки das.isolationaddress0 и das.isolationaddress1.
Таким образом мы получаем следующие рекомендуемые настройки растянутого кластера HA совместно с кластером Virtual SAN:
vSphere HA
Turn on
Host Monitoring
Enabled
Host Hardware Monitoring – VM Component Protection: “Protect against Storage Connectivity Loss”
Disabled (по умолчанию)
Virtual Machine Monitoring
Опционально, по умолчанию "Disabled"
Admission Control
30-50% для CPU и Memory.
Host Isolation Response
Power off and restart VMs
Datastore Heartbeats
Выбрать "Use datastores only from the specified list", но не выбирать ни одного хранилища из списка
Ну и должны быть добавлены следующие Advanced Settings: